As will be understood by those skilled in the art, Object-Oriented Programming (OOP) techniques involve the definition, creation, use and destruction of "objects". These objects are software entities comprising data elements and routines, or functions, which manipulate the data elements. The data and related functions are treated by the software as an entity that can be created, used and deleted as if it were a single item. Together, the data and functions enable objects to model virtually any real-world entity in terms of its characteristics, which can be represented by the data elements, and its behavior, which can be represented by its data manipulation functions. In this way, objects can model concrete things like people and computers, and they can also model abstract concepts like numbers or geometrical designs.
A full discussion of the object-oriented terms, notation and diagrams used in this disclosure is provided in "Object-Oriented Analysis and Design", edited by Grady Booch, and published by Benjamin Cummings, 1994. A brief overview of the Booch notation is shown in FIG. 5 with a class 22 being denoted by an amorphous blob, and a utility procedure 24 by a shadowed amorphous blob. A class category 26 is denoted by a rectangle, and contains a collection of related classes. A parameterized class 28 is denoted by an amorphous blob with a rectangle for the formal arguments 30, and an instantiated parameterized class 32 is denoted by an amorphous blob with a rectangle for the actual arguments 34. Relationships between the classes are denoted by an association line 36, inheritance arrow 38, "has a" solid circle line 40, and "uses" open circle line 42. Links between calling 43 and called 45 objects are denoted by an order:message arrow 44 and an object/value open circle arrow 46. Also shown is the symbols for denoting class properties 48 and the naming convention 50. The visibility of the called object 45 in relation to the calling object 43 is depicted by the letters G, P, F, and L, enclosed in a square 51 and representing Global, Parameter, Field ("part of" relationship), and Local respectively.
Provided bellow are definitions of some object oriented terms used in this disclosure:
base class the most abstract class of a framework from which all other classes are derived. PA1 super class a class from which other classes are derived. PA1 subclass a class that is derived from one or more super classes. PA1 abstract class A class that defines abstract behavior and is used only as a super class for other subclasses, where the subclasses implement the abstract behavior. No instances are derived from an abstract class. PA1 pure virtual method A method of an abstract class that must be overridden and implemented in a subclass. PA1 concrete class A class that is complete in its implementation and may therefore have instances. A concrete class can also be a super class to other subclasses. PA1 primitive type A data simple data type such as an integer, unsigned integer, long, character, etc. PA1 extended type A complex data type such as an object. PA1 File Name An ASCII string is used for identifying the file. Some systems allow the file name to include the path name for specifying the volume and directory where the file is located. An example path name is: Volume1:Directory1:Filename. PA1 Creation Time The time and date the file was created. PA1 Modification Time The time and date the file was last changed. PA1 Type The type of file (application file, data file, etc.). PA1 Home File System The file system that created the file (MS-DOS, HFS, AppleShare, NFS, etc.). PA1 Open State Specifies whether the file has been opened for accessing. PA1 Physical Size The number of bytes currently allocated for the file. PA1 Actual Size The number of bytes currently used by the file. PA1 Access Control Protection mechanism for controlling access to the file. PA1 Permissions Specifies operations permitted (read only, read/write, shared read, shared read/write, etc.). PA1 Principle Owner of the file. PA1 Position Pointer into the file data where the next read or write will begin. PA1 Create A file is created and initialized with specified properties. PA1 Delete When a file is no longer needed, it is deleted to free up disk space. PA1 Open Before accessing a file, an application must open it. The purpose of the Open is to load the file's properties into main memory for access by subsequent file system calls. PA1 Close When an application is finished accessing a file, the properties are no longer needed, so the file is closed to free up the main memory. PA1 Read An application reads data from a file into a specified buffer. Reading normally begins at the current position. PA1 Write An application writes data to a file from a specified buffer. Writing normally begins at the current position. PA1 Seek An application can seek to a specific position in the file before reading or writing. PA1 Get and Set Properties Provides application access to the file properties. An application may need to read or modify the file properties. For instance, an application may need to display the file names and types in an open dialog, or re-name a file, or modify the permissions, or modify the access control, etc. PA1 Range Locking If the permissions of a file allows multiple writers, each writer can lock a range of data to prevent multiple writes to the same data. PA1 Directory Name An ASCII string is used for identifying the directory. Some systems allow the directory name to include the path name for specifying the volume and directory path where the directory is located. An example of a directory path name is: Volume1:Directory1:. PA1 Creation Time The time and date the directory was created. PA1 Modification Time The time and date the directory was last changed. PA1 Home File System The file system that created the directory (MS-DOS, HFS, AppleShare, NFS, etc.). PA1 Physical Size The number of bytes currently allocated for the directory. PA1 Actual Size The number of bytes currently used by the directory. PA1 Access Control Protection mechanism for controlling access to the directory. PA1 Principle Owner of the directory. PA1 Create A directory is created and initialized with specified properties. PA1 Delete When a directory is no longer needed, it is deleted to free up disk space. PA1 Get and Set Properties Provides application access to the directory properties. An application may need to read or modify the directory properties. For instance, an application may need to display the directory names in an open dialog, or re-name a directory, or modify the access control. PA1 Volume Name An ASCII string is used for identifying the volume. PA1 Creation Time The time and date the volume was created. PA1 Modification Time The time and date the volume was last changed. PA1 Home File System The file system that initialized the volume (MS-DOS, HFS, AppleShare, NFS, etc.). PA1 Physical Size The number of bytes currently allocated for the volume. PA1 Actual Size The number of bytes currently used by the volume. PA1 Access Control Protection mechanism for controlling access to the volume. PA1 Mount Volume A volume must be mounted before it can be accessed. PA1 Unmount Volume A volume is unmounted when it is no longer needed. PA1 Initialize A volume is initialized and formatted for the specific home file system.
Objects are defined by creating "classes" which are not objects themselves, but which act as templates that instruct the compiler how to construct an actual object. A class may, for example, specify the number and type of data variables and the steps involved in the functions which manipulate the data. An object is actually created in the program by means of a special function called a "constructor" which uses the corresponding class definition and additional information, such as arguments provided during object creation, to construct the object. Likewise objects are destroyed by a special function called a "destructor". Objects may be used by manipulating their data and invoking their functions.
The principle benefits of object-oriented programming techniques arise out of three basic principles; encapsulation, polymorphism and inheritance. More specifically, objects can be designed to hide, or encapsulate, all, or a portion of, the internal data structure and the internal functions. During program design, a program developer can define objects in which all or some of the data variables and all or some of the related functions are considered "private" or for use only by the object itself. Other data or functions can be declared "public" or available for use by other programs. Access to the private variables by other programs can be controlled by defining public functions for an object which access the object's private data. The public functions form a controlled and consistent interface between the private data and the "outside" world. Any attempt to write program code which directly accesses the private variables causes the compiler to generate an error during program compilation which error stops the compilation process and prevents the program from being run.
Polymorphism is a concept which allows objects and functions which have the same overall format, but which work with different data, to function differently in order to produce consistent results. For example, an addition function may be defined as variable A plus variable B (A+B) and this same format can be used whether the A and B are numbers, characters or dollars and cents. However, the actual program code which performs the addition may differ widely depending on the type of variables that comprise A and B. Polymorphism allows three separate function definitions to be written, one for each type of variable (numbers, characters and dollars). After the functions have been defined, a program can later refer to the addition function by its common format (A+B) and, during compilation, the C++ compiler will determine which of the three functions is actually being used by examining the variable types. The compiler will then substitute the proper function code. Polymorphism allows similar functions which produce analogous results to be "grouped" in the program source code to produce a more logical and clear program flow.
The third principle which underlies object-oriented programming is inheritance, which allows program developers to easily reuse pre-existing programs and to avoid creating software from scratch. The principle of inheritance allows a software developer to declare classes (and the objects which are later created from them) as related. Specifically, classes may be designated as subclasses of other base classes. A subclass "inherits" and has access to all of the public functions of its base classes just as if these function appeared in the subclass. Alternatively, a subclass can override some or all of its inherited functions or may modify some or all of its inherited functions merely by defining a new function with the same form (overriding or modification does not alter the function in the base class, but merely modifies the use of the function in the subclass). The creation of a new subclass which has some of the functionality (with selective modification) of another class allows software developers to easily customize existing code to meet their particular needs.
Although object-oriented programming offers significant improvements over other programming concepts, program development still requires significant outlays of time and effort, especially if no pre-existing classes are available for modification. Consequently, a prior art approach has been to provide a program developer with a set of pre-defined, interconnected classes which create a set of objects and additional miscellaneous routines that are all directed to performing commonly-encountered tasks in a particular environment. Such pre-defined classes and libraries are typically called "application frameworks" and essentially provide a pre-fabricated structure for a working application.
For example, an application framework for a user interface might provide a set of pre-defined graphic interface objects which create windows, scroll bars, menus, etc. and provide the support and "default" behavior for these graphic interface objects. Since application frameworks are based on object-oriented techniques, the pre-defined classes can be used as base classes and the built-in default behavior can be inherited by developer-defined subclasses and either modified or overridden to allow developers to extend the framework and create customized solutions in a particular area of expertise. This object-oriented approach provides a major advantage over traditional programming since the programmer is not changing the original program, but rather extending the capabilities of the original program. In addition, developers are not blindly working through layers of code because the framework provides architectural guidance and modeling and, at the same time, frees the developers to supply specific actions unique to the problem domain.
There are many kinds of application frameworks available, depending on the level of the system involved and the kind of problem to be solved. The types of frameworks range from high-level application frameworks that assist in developing a user interface, to lower-level frameworks that provide basic system software services such as communications, printing, file systems support, graphics, etc. Commercial examples of application frameworks include MacApp (Apple), Bedrock (Symantec), OWL (Borland), NeXT Step App Kit (NEXT), and Smalltalk-80 MVC (ParcPlace).
While the application framework approach utilizes all the principles of encapsulation, polymorphism, and inheritance in the object layer, and is a substantial improvement over other programming techniques, there are difficulties which arise with the prior art application frameworks. Typically, application frameworks generally consist of one or more object "layers" on top of a procedure based operating system and even with the flexibility of the object layer, it is still often necessary to directly interact with the underlying operating system by means of awkward and inefficient procedure calls. In the same way that an application framework provides the developer with prefab functionality for an application program, a system framework, such as that included in a preferred embodiment, can provide a prefab functionality for system level services which developers can modify or override to create customized solutions, thereby avoiding the procedural calls necessary with the prior art application frameworks. For the commercial or corporate developer, systems integrator, or OEM, this means all of the advantages that have been illustrated for a framework, such as MacApp, can be leveraged not only at the application level for such things as text and user interfaces, but also at the system level, for services such as printing, graphics, multi-media, networking, I/O, and, as described herein, file systems.
A major part of computer operating systems is the system responsible for handling information stored in files. There are file systems designed for single processor systems such as Macintosh Hierarchical File System (HFS) and MS-DOS, or multiple processor distributed file systems such as AppleShare, Sun Network File System (NFS), or UNIX file system. A distributed file system is normally a super set of a single processor file system, that is, a distributed file system normally has all the features and capabilities of a single processor system except that it is distributed over several computers using a network. A full discussion of Macintosh HFS and AppleShare file systems is provided in "Inside Macintosh Volume IV, V, VI", published by Addison Wesley, and a discussion of MS-DOS, NFS, UNIX, and other file systems is provided in "Modern Operating Systems", edited by Andrew S. Tanenbaum and published by Prentice Hall. These file systems have a common architecture and provide similar capabilities.
Normally, file data is stored in non-volatile storage mediums such as disk drives. A computer usually has access to one or more disk drives connected directly to it, and may have access to disk drives connected to other computers through a network. Each storage device or disk drive is normally represented by a volume, however a disk can be partitioned into multiple volumes. A volume contains a directory tree where each node in the tree is a unique directory. A directory contains a collection of files which are the leaves of the tree, and can also have branches represented by subdirectories, where each subdirectory also contains files and may branch into further subdirectories. A volume is also the root of the directory tree 2 as shown in FIG. 1. To access a file, the user specifies the volume and directory where the file is located.
Volumes, directories, and files are entities with specific information and functions associated with each. The information associated with a file system entity is referred to as the attributes or properties, and the functions define the operations for manipulating these properties. There are also functions for retrieving and storing the contents of a file system entity, but the file system normally does not know or care about what is in the file. Interpreting the data content and format is done at the application level, while the file system is responsible for handling application requests such as retrieving information about a file, or storing and retrieving file data. The disclosure herein discusses the most common properties and functions provided by the different file systems.
Files
Files are entities for storing application and operating system data in a variety of formats including binary and ASCII records. Each file has associated with it specific properties used by the file system for handling application requests. Common properties for a file include:
The file properties are used at both the operating system and application level. For instance, an application may need to acquire the name and type of a file for displaying in an open file dialog. Applications obtain access to file properties and file data through operations provided by the file system. Common file operations include:
Directories
The file system stores files in a directory tree as shown in FIG. 1. The root directory 2 is also the volume where the directory tree is located. Each directory can contain a collection of files 4 and subdirectories 6 where subdirectories are further branches in the directory tree. Directories have properties used by the file system for handling application requests which are similar to the file properties. Common properties for a directory include:
The file system also provides operations for handling requests by an application for accessing directories. Common directory operations include:
Volumes
A disk drive normally represents one volume 2 as shown in FIG. 1, but it can also be partitioned into several volumes. A volume is also the root directory of the directory tree stored on the volume. Volumes are either mounted or unmounted, and a computer does not have access to a volume until it is mounted. Volumes also have properties used by the file system for handling application requests. Common properties for a volume include:
The file system also provides operations for handling requests by an application for accessing volumes. Common volume operations include:
Not all file systems provide all of the above listed properties and operations, and some systems provide additional properties and operations. However, most all file systems implement the operations for manipulating the properties and file data using traditional procedural programming.
In procedural programming, the data is separate from the operations on the data. When developing procedure based systems, the programmer defines the data and the operations on the data separately. Further, the data structures which represent the file system entities are "flat" rather than "hierarchical" due to the lack of inheritance. This separation of data from function results in less reliable and less extensible code, the two primary factors behind the promulgation of object-oriented programming.
There have been attempts to integrate the benefits of object-oriented programming into the entities of a procedural based file system by including file entity classes as part of an application framework. For instance, in Apple Computer's application framework for the Macintosh operating system (MacApp) a TFile class 8 is provided as an interface to the procedure based file system (see "Programmer's Guide to MacApp", Developer Technical Publications, 1992). Another example is the CFile class provided in Visual C++, Microsoft's application framework for the Windows operating system (see "Visual C++, Reference Volume I", Microsoft, 1993). An abbreviated version of the MacApp TFile class 8 as shown in FIG. 3A encapsulates the properties, data, and operations of a Macintosh file into a standard object-oriented class that programmers are familiar with. However the benefits of object-oriented programming (mainly extendibility) are not realized with this implementation because the underlying design is still procedural.
A programmer cannot extend the MacApp TFile class by adding new properties and operations into a subclassed file because the Macintosh file system itself cannot be extended. The properties and operations defined for the Macintosh file system entities are fixed, and because they are procedural, they cannot be extended. The only way Apple has added additional properties or functions to the Macintosh file system entities has been to release a new version of the operating system. Having to release a new version of the operating system to extend the capabilities of the file system is undesirable.
File Data Access
In addition to providing operations for manipulating file properties, file systems provide a means for reading and writing file data. In prior art file systems, data is read from and written to a file using standard procedural calls as shown in FIG. 6. For the Macintosh, data is read from a file using FSRead 54 and data is written to a file using FSWrite 52. Both procedures take a file reference number 56, a count 58 number of bytes to be read/written, and a buffer 60 to read data into or write data from.
The problem with accessing file data with standard procedures is that structured data such as objects must be "flattened" into a linear sequence of bytes before being written to the file. This is especially burdensome when an object encapsulates other objects which must also be "flattened" in the correct order. Similarly, when reading data from a file, the exact ordering used to write the data must be re-created, and as the data is read, it must be typed coerced before being assigned back to an object.
To overcome these problems, application frameworks such as MacApp provide a stream class for reading and writing file data (see "Programmers Guide to MacApp", Developer Technical Publications, 1992, at p. 416-423). The stream class provides a convenient general means for accessing file data, including methods for reading and writing primitive data types such as bytes, integers, and characters. A stream can also be subclassed for reading and writing other extended data types such as objects. Although the stream class greatly simplifies the task of manipulating file data in an object-oriented application, there are problems with these prior implementations.
Even though the task of accessing file data is encapsulated into the prior art stream class, the stream's TFile 8 still must make the standard read/write procedure call 62 provided by the procedure based file systems as shown in FIG. 6. Having to call the file system procedure 62 adds an extra layer of overhead resulting in longer file access times. Since file access is usually the largest bottleneck in an operating system, increasing the access time is extremely undesirable. The present invention overcomes this problem by incorporating the prior art procedure call 62 into the TFile class, thereby reducing the overhead by obviating the additional procedure call.
Searching
A further feature provided by most file systems is the ability to perform searches to retrieve specific entities and their properties. For instance, a user might want to search a volume for a specific file or directory, or to retrieve all the files of a given type. An example would be to search a volume for a file named "document.doc", or to retrieve all the files of type "source code" from a directory. Most file systems provide a limited capability, if any, for searching for entities and their properties.
Apple's Macintosh file system for operating system 7 provides the ability to search volumes using a procedure called PBCatSearch (see "Inside Macintosh, Volume VI", pages 25-20 to 25-25, edited by Addison Wesley). PBCatSearch allows a programmer to search for a group of files or directories based on a set of properties. The programmer fills out a record defining the set of properties for the entities being searched, and sends the record to the PBCatSearch procedure. Also provided is the ability to specify a range of values for the properties such as entity size or creation date. For instance, a programmer can search for all the files whose names contain the string "Temp" and that were created within the past two days. Because PBCatSearch arid the Macintosh file system are procedural, the capabilities are limited in many respects.
Using PBCatSearch, the user cannot perform searches to retrieve a group of file system entities that contains both files and directories. Also, a user cannot perform searches based on entity properties other than those implemented by PBCatSearch, and the types of range queries is limited to only a few properties such as size and date. Further, since the properties of the Macintosh file system cannot be extended, the ability to perform custom storage and retrieval is not possible. These limitations are due in large part to the fact that the Macintosh file system is procedural rather than object-oriented.
Notification
Many object-oriented application frameworks provide the ability to create object dependencies. An object dependency is established when one object in the system needs to be notified when another object has been changed. For instance, a view represented as one object might display data represented by another object. The view object needs to be notified when the data object has changed so the view object can display the new data, therefore a dependency is established between the view object and data object. An example of such dependency capability is provided by Apple's MacApp application framework as described in "Programmers Guide to MacApp", Developer Technical Publications, 1992, at p. 52. Although the dependency and notification ability is provided by application frameworks, the concept has not been incorporated into prior art file systems because they are not object-oriented.
User Authentication
Another feature provided by operating systems is security against unauthorized access to file system entities. For instance, access to a volume, directory, or file might be restricted to a particular user, so the operating system provides a means for preventing access to anyone other than the authorized user. User authentication is normally implemented by the users entering their identification and a password which is verified by the local authentication service.
Protection Domains
Most operating systems provide a further level of protection for file system entities called protection domains. A protection domain is defined as a set of {Object, Rights} pairs. For a file system, the objects are the file system entities and the rights are read, write, execute, etc. An example of a file system protection domain is shown in FIG. 3B. Domain1 10 has read access to File1 and read/write access to File2, Domain2 12 has read/execute access to File3 and read access to File4, Domain3 14 has read access to File4 and read/write access to File5.
In a file system, the protection domains are represented as a user or a group. The accessible files and access rights are defined for each domain. As an example, a user may belong to a group which has access to a particular number of executable files, as well as exclusive access to personal data files. For instance, a teacher may have access to a word processing and grading program and exclusive access to student data files. The students, as a group, may have access only to the word processing file, and each student may have exclusive access to their own personal data files.
Foreign File Systems
Some file systems are compatible with other foreign file systems running under different operating systems. For instance, the Macintosh AppleTalk Filing Protocol (AFP) described in "Inside AppleTalk", edited by Gurshran S. Sidhu et al and published by Addison Wesley, was designed specifically to allow workstations to share files across a network with remote servers running different operating systems. This transparency is accomplished with a special AFP program running on both the workstation and the server with the remote volumes.
The AFP program running on the workstation communicates with the AFP program running on the remote server over the network. Remote volumes connected to the remote server are mounted for access by applications running on the workstation. When an application running on the workstation makes a file request using the native file system, the AFP program determines if the file is located on a remote volume. If the file is located on a remote volume, the AFP program running on the workstation translates the native file system request into an AFP format, and sends the AFP request to the AFP program running on the remote server. The AFP program running on the remote server handles the file request and sends an AFP response to the AFP program running on the workstation. The AFP program running on the workstation translates the AFP response from the remote server back into the native file system format of the workstation, and the native response is sent to the application which made the original file request. Using AFP, any application running on a workstation has transparent access to remote volumes connected to servers running different operating systems.
A major drawback with the AFP system is that AFP programs must be written for every workstation and remote server running different operating systems. Since AFP was implemented using traditional procedural programming, writing the AFP programs is more difficult because a programmer starts only with the specification of the AFP protocol. The entire AFP program must be designed, implemented, and debugged. The result is a longer development time and less reliable programs. Longer development time and less reliability are problems inherent in procedure based programs. The present invention overcomes these problems because the file system is implemented with object-oriented programming, a technology which facilitates extendibility.
Another major problem with the AFP system is the significant latency caused by accessing the remote files over the network. Access times for local volumes is only a few milliseconds, but every remote file access suffers the additional delay in transmitting a request and receiving a response over the network. These delays can amount to several seconds for every file request. For many applications where file access time is critical the network delays are simply unacceptable.
The present invention overcomes this problem because compatibility with foreign file systems is accomplished at the file system entity level. A file from a remote server running under a different operating system is packaged into a format compatible with the file system of the present invention. The packaged file can be transported over the network to the workstation's local volume for direct accessing, and when the application is finished with the file, it is transported back to the server's volume and unpackaged back into the server's file system format.
It is, therefore, a main object of the present invention to provide an extensible object oriented file system in an object oriented operating system by providing a category of file system classes which encapsulate a plurality of properties from a category of property classes, with support for batch and query search and retrieval, and support for notification, user authentication, protection domains, and interoperability with foreign file systems.